Términos Fundamentales de IA
Hace no mucho, si alguien en una reunión técnica mencionaba un LLM o hablaba de tokens y context windows, lo normal era asentir con cara de póker y buscarlo en Google después. Eso ha cambiado bastante rápido. Demasiado rápido, de hecho. De repente la IA ha dejado de ser "ese tema que llevan los del laboratorio de ciencia de datos" para convertirse en algo que afecta directamente al trabajo del día a día de cualquier persona en infraestructura, operaciones o soporte.
El problema es que la curva de entrada no está bien señalizada. Hay una avalancha de contenido sobre IA, sí, pero la mayor parte está escrita para dos perfiles muy concretos, investigadores con fondo matemático o gente de negocio que solo quiere subirse a la ola.
El técnico IT que lleva años montando servidores, gestionando Docker, automatizando scripts y peleando con alertas a las tres de la mañana no suele encontrar contenido que hable su idioma. Y eso genera una sensación muy incómoda, la de estar en una conversación donde todo el mundo parece entender algo que tú no terminas de pillar del todo.
Este artículo intenta cubrir ese hueco. No desde cero como si no supieras nada, sino partiendo de que ya tienes base técnica real y solo necesitas que alguien te explique bien de qué va esto sin ponerse filosófico ni darte una clase magistral.
LLM: El concepto que lo sostiene todo
Un Large Language Model, o LLM, es el tipo de sistema que hay detrás de herramientas como ChatGPT, Claude o Llama. La idea básica es que se trata de una red neuronal entrenada con cantidades enormes de texto, libros, webs, código, foros o documentación, con el objetivo de aprender los patrones del lenguaje. No aprende reglas explícitas, aprende estadística del lenguaje. Lo que hace cuando le escribes algo es, técnicamente, predecir cuál es la continuación más probable de ese texto.
Dicho así suena casi decepcionante. Pero ese mecanismo tan simple, escalado a cientos de miles de millones de parámetros y entrenado con datos de calidad, produce algo que se comporta de forma útil en situaciones muy diversas, analizar logs, clasificar errores, responder preguntas técnicas, generar código o resumir documentación.
Lo que no hace, y esto es importante entenderlo bien, es razonar en el sentido humano. No tiene conciencia del contexto fuera de lo que le envías en cada llamada. No recuerda conversaciones anteriores salvo que se las pases explícitamente.
- Funciona como una función pura: Entrada -> Salida.
Eso condiciona mucho cómo se integra en sistemas reales.
Token: La unidad de medida que nadie te explica bien
Cuando trabajas con LLMs, todo se mide en tokens. No en palabras, no en caracteres, tokens. Un token es aproximadamente 0,75 palabras en inglés. En español el ratio baja un poco porque nuestras palabras tienden a ser más largas. La palabra "configuración" son unos 5 tokens. "API" es 1.
¿Por qué importa esto? Por dos razones muy concretas:
- Primero, los modelos tienen un límite de tokens que pueden procesar en una sola llamada, lo que se llama context window. Si el modelo tiene 128.000 tokens de context window, puedes enviarle aproximadamente 90.000-100.000 palabras de una vez. Eso es mucho, pero si estás enviando logs largos, historial de incidentes y documentación de sistema, puedes llegar al límite más rápido de lo que parece.
- Segundo, los servicios de API se cobran por tokens consumidos. Tokens de entrada (lo que envías) y tokens de salida (la respuesta). Para tareas de clasificación, que es exactamente lo que necesitas en AIOps (Inteligencia Artificial para Operaciones de TI), por ejemplo, la respuesta suele ser brevísima, "REINICIAR" o "INFORMAR", dos o tres tokens. El coste por análisis acaba siendo de fracciones de céntimo, lo cual hace que la escala sea perfectamente viable incluso para entornos con mucho volumen.
System Prompt y Temperatura: Los controles que más usarás
Cuando integras un LLM en una aplicación real, no le escribes mensajes como si fuera un chat. Usas dos mecanismos distintos. El primero es el system prompt, un bloque de instrucciones fijas que define quién es el modelo y cómo debe comportarse. Es lo equivalente a darle unas instrucciones antes de empezar a trabajar. Ahí defines su rol, sus restricciones y el formato de respuesta que esperas.
La temperatura es otro parámetro que controla cuánta variabilidad hay en las respuestas:
- Temperatura 0 significa que el modelo siempre elige la opción más probable, lo que produce respuestas consistentes y repetibles.
- Temperatura alta introduce más aleatoriedad, útil si quieres respuestas creativas o variadas. Para tareas de operaciones, clasificación de fallos o generación de alertas, temperatura cero o muy baja es lo que quieres. No necesitas creatividad, necesitas consistencia.
El prompt engineering, el arte de escribir bien estas instrucciones, es probablemente la habilidad más práctica para alguien que empieza a trabajar con LLMs. No es difícil, pero sí requiere iterar.
Un prompt vago produce respuestas vagas. Si le dices al modelo "eres un experto en sistemas, analiza este log y dime si debo reiniciar el contenedor", las respuestas van a ser heterogéneas. Si le dices exactamente qué categorías puede devolver, qué criterios usar para cada una y en qué formato exacto quieres la respuesta, el comportamiento se vuelve mucho más predecible.
Local vs API: La decisión que más condiciona el diseño
Una de las primeras decisiones cuando montas algo con LLMs es si corres el modelo en tu propia infraestructura o usas una API externa. No hay respuesta universal, pero sí hay consideraciones claras.
- Correr un modelo en local, con herramientas como Ollama, significa que los datos nunca salen de tu red. Si trabajas en entornos con restricciones de privacidad, logs con información sensible o simplemente no quieres dependencia de terceros, esto pesa mucho. El coste operativo es el hardware, necesitas GPU con suficiente VRAM para cargar el modelo. Un modelo de 8 mil millones de parámetros en precisión completa ocupa unos 16 GB de VRAM. En cuantización a 4 bits baja a 5 GB, con algo de pérdida de calidad.
- La API de un proveedor como Anthropic o OpenAI te da acceso a modelos más potentes sin preocuparte de infraestructura. La latencia suele ser buena para tareas de clasificación, del orden de uno a tres segundos, y el coste por llamada es pequeño si el volumen no es extremo. La contrapartida es que los datos salen de tu red y tienes dependencia de un servicio externo.
En muchos casos el modelo híbrido tiene sentido, modelo local para el volumen de análisis rutinario, API para los casos donde necesitas mayor precisión o capacidad de razonamiento.
VRAM, Context Window y Rate Limiting: Los tres límites que te vas a encontrar
Cuando algo falla en producción con LLMs, suele ser por uno de estos tres motivos.
- La VRAM es el techo físico del modelo local, si intentas cargar un modelo que no cabe, o cae a RAM del sistema y se vuelve inutilizablemente lento, o directamente da error.
- El context window es el techo lógico, si el texto que envías supera la ventana del modelo, tienes que truncar, resumir o paginar, y eso requiere diseño previo.
- El rate limiting es el techo operativo de las APIs externas, límite de peticiones por minuto y de tokens por minuto. En un entorno tranquilo no lo notas. Pero si tienes un incidente mayor con veinte contenedores fallando simultáneamente y todos intentan lanzar análisis a la vez, puedes empezar a recibir errores 429 ("Too Many Requests", que alguna vez habéis encontrado en otros entornos).
Por llevarlo a la tierra, imagina que hay un único cajero en el supermercado y de repente se forman diez colas a la vez. Si todo el mundo empuja al mismo tiempo, el sistema colapsa. La solución sensata es que la gente haga fila ordenadamente y, si el cajero está ocupado, espere un momento antes de intentarlo de nuevo.
En software funciona igual. Cuando la API dice "estás enviando demasiadas peticiones a la vez", en vez de que todos los análisis fallen a la vez y el sistema se rompa, los pones en una cola ordenada. El primero espera 1 segundo antes de reintentar, si vuelve a fallar espera 2, luego 4, luego 8... esa progresión que dobla el tiempo en cada intento es lo que se llama "exponencial". Así el sistema se autorregula sin saturar la API ni perder ningún análisis por el camino.
Lo que necesitas saber de IA para empezar a construir cosas reales
Hay algo que suele pasarles a los técnicos IT cuando empiezan a "trastear" con todo esto, en algún punto dejan de ver los LLMs como una caja negra misteriosa y empiezan a verlos como una herramienta más, con sus límites claros y sus patrones de fallo conocidos. Ese cambio de perspectiva es el que realmente desbloquea las posibilidades prácticas.
No hace falta saber cómo está construido por dentro ni haber estudiado nada especial. Hace falta entender qué entra, qué sale, qué puede fallar y cómo manejar esos fallos. Exactamente igual que con cualquier otra pieza de infraestructura.
El vocabulario que acabas de leer no es el final del camino, pero sí es el mapa mínimo para no perderte en las primeras conversaciones, y para empezar a construir cosas que funcionen de verdad.
Fin del Artículo. ¡Cuéntanos algo en los Comentarios!
